ETH2.0: Cross-shard Communication

Overview

Contracts can specify their own conditions for when they get yanked

For usability perspective, contract separates out the state related to individual interactions so that it can be moved between shards separately

Automatic yanking

Address format

Cross-shard receipt creation and inclusion: Introduce special pre-compiles (cross-shard sender/receiver)

Withdrawing from the beacon chain

Synchronous

References

Makes it impossible to have two transactions at the same height that affect the same account

On-chain Plasma

Application design

Cases which can be done with "move things to the same shard and execute" scheme is introduced

but neither synchronous (e.g. using the data from an oracle immediately) nor atomic (e.g. risk-free arbitrage between Uniswap and some other single-threaded DEX on some other shard)

Devide a single-threaded apps (e.g. Uniswap) into a single executor and multiple sequencers

This way, non-core logic (e.g. signature verification) can be parallelized

Codes shared between many usecases are put on the beacon chain

E.g. Cryptographic algorithms, smart contract wallet implementations, token contract implementations (, and execution environments)

Other Resources

Master thesis